Cooperation Policies for Traders

[NiGo94] Y. Ni and A. Goscinski. Trader cooperation to enable object sharing among users of homogeneous distributed systems. been described in section 3 are applied. This means answering the questions of the introduction either by the system administrator or automatically. In a next step, cost and security aspects will be included. To prepare this, cost have already been included in the general model. The need for security could either be appended to each of the trader's facilities or introduced as a global goal. 5 SUMMARY By considering a general cooperation model, we found a large variety of different types of traders with respect to their facilities, goals, and weights of goals and identified two main cases of cooperation policies. These cooperation policies can be realized by means of quantifying the goals of traders and observing and analysing the behaviour of clients, servers and traders. Furthermore , an adaptation mechanism for the second class of cooperation policies has been defined. Collecting those aspects, answers to all questions posed in the introduction have been found: • Determination of conditions leading to a cooperation respectively to its end (subsection 2.3 and 3.2). • Finding out the service types to be imported or exported by the cooperation (subsection 3.2). • Determination of the cooperation form to be applied (subsection 3.3). Thus, traders are equipped with policies to decide on cooperation automatically. This contributes directly to ODP trading. [Burg90] C. Burger. Performance optimization in heterogeneous distributed systems by dynamic allocation of user tasks (in german). [BuSe94] C. Burger and F. Sembach. A survey of mechanisms for computer supported cooperation (in german). behaviour. Cases in which the quality of trader service decreases independently of any cooperation , have to be filtered out. For example, the response time of a trader without cooperation has to be estimated to find out the reason for an increase. The functionality of an isolated trader has been implemented in the MELODY project (Management Environment for Large Open Distributed sYstems) and is documented in [KoWi94]. The architecture consists of two main parts, the trader user agent (TUA) that is bound to clients and servers and the trader server agent (TSA). The agents are written in C++ and communicate via DCE-RPC, therefore object adapters (OA) are needed to map from the object oriented to the procedural model (cf. figure 3). MELODY traders take into account dynamic properties of servers. This is achieved by …